> > SNIP..  Parse error in ppshort1.pov at Line: 568.

Thanks for your work around, I will give this a whirl.  It was ppRod character
that brought me face to face with this error.  Now that I know a way around it,
I would get to see ppRod as well.
>
> Snip.. your  work around recommendations.

> Basically the 'trace' command fires out rays to find points on an object
> along the line of the ray. The reason I mention this is that this command is
> what I used in the ppCrowd macros to detect points on a surface. You may
> wish to consider that technique as a way of implementing collision
> detection.

Cool, pointer.  Let me  print this email, highlight it put it in front of me, I
have a feeling it might get me unstuck in trying to translare my humanoid
forward as he steps forward.

> > I am hoping the rest of POV_person doc is going to allow me to learn how
> > to
> > easily change the clothing and appearance of the person I would start
> > animating.
> >
>
> The documentation should cover how to adjust the colours, surface normals
> and other attributes of the existing clothing. Each item of clothing is
> driven by a macro and has as many controls as I could think of building in,
> so, for example, the trousers allow you to control the length

True, not knowing the length of Characters' legs, or upper legs, down to middle
of calves, etc.. how could one pick up reasonable values for trouser lengths?

> whether it
> has seams, how wrinkly the material is etc. and these settings are described
> briefly in '06variables.html'.

> For example you can use ppHeelHeight to
> reduce the size of the heels on the boots.

While I was looking at the ppboot1.inc, I noticed a global scoped variable for
heel size, but, was afraid shortening heels won't be enough to turn a boot into
a sneaker.  How about Legging, part? this and that.  Being a very visual person
I am, I was hoping for a visual reference of a boot that showed how so mny pp
variable names mapped to different parts of the boot, so, I could begin the
disection.  There comes my limited knowledge of POV-RAY, I guess a POV-RAY
expert could use a torus object to create the ties on the sneakers in a snap.

And I sort felt clueless where to start in creating a form fitting sweartshirt,
better yet, I have a picture of a Chinese fabric that could make the front
panels of the Gi top.  With Chineese writing.  Well, the character I want to
create has to represent the Yin-Yang, energy principals of the culture it was
born in.

I am a figuritive sculptress on my free times, I hope there is sofware that
would allow me to digitally mold my 3D characters.  Modo was mentioned as the
only modern 3D sculpting tool.  In the URL I had mentioned.
>
> > Might you have any design doc that pictorially outlines the calling
> > sequence.
>
> I have a diagram, but it corresponds more closely to a later version which
> followed a significant reorganisation of the code that I never got round to
> publishing. I'm happy to send you a copy so long as it's not going to be
> confusing. Do you have PowerPoint?

Yes, I do.
>
> > In
> > a way, it appears to me, ppann, ppalf, ppbill, etc acting like instances
> > of
> > pphuman0001.
>
> Really ppann, ppalf, ppbabs and ppbill, (along with pprod and ppsanta) are
> just settings for predefined characters. The corresponding files contain
> settings that control the character. To create a new character you can just
> copy a file and change the variable settings in your new file.  The file
> 'pphuman001.inc' contains the anatomical definition on which all of these
> characters are currently based. However, it would be possible to create an
> alternative anatomy by copying 'pphuman001.inc' and adjusting the body parts
> and joint definitions. I've been meaning to define a quadraped for quite
> some time.

Thanks for taking the time and responding.  I was just throwing in OOP
terminology, without making my thinking clear.  ppHuman0001.inc acted like your
Human object's class definition.  It knew about the anatomy of humanoid skeletal
being created.  It has bunch of class variables, and bunch of macros acting as
class methods, such as AddJoint, RotateJoint, MirrorPose, etc.

All of your characters, they defined specific values for the instances of the
human0001 variables, so that particular instance of class Human001 become
distinguisable from other instances of class Human001.

From my perspective, you used a language that offered no official OOP support in
a very sophisticated way as if it had.


>
> > I wonder if ppmale, ppfemale would have made sense, before
> > instances?
>
> The ppGender variable is used to stipulate the gender. This is set at the
> top of each character file.

Thanks, I noticed ppGender being a class attribute (=variable) after I wrote to
you my comments.  There is just so many ways to eat the cake.

I used to have Visio to diagram for my evolving design ideas.  Not anymore, I
want it now.  I wonder why people dread writing desing docs.  It has always
been one creative outlet for me.   Anyhow.  W/o diagramming here is a simple
textual class hierarcy I see

                    Skeletal Being
                   /        |     \
              Humanoid    Robot  Quadraped
              /       \      |     /   \
           Male      Female Rod  Quasy Legsie
           /  | \    /  |  \
         ppm1 |  Randy ppf1 ppf2
         /  | ppsanta   |     |
      Alf  Bob         Ann   Babs

I don't know if this will display correctly, we shall see.


> > It also appears to me the MODEL of human is a skelatal being made
> > up of joints and segments.  It appears to me you partioned the space of
> > humanoid object properties into properties that define
> >  (a) the character (b) the style, (c) the expression, (d) the "pose", and
> > (e)
> > the outfit
> >
> > Which happened to be the parms one passes to ppFigure.
>
> That's true in this version. Later on I realised that this was too
> restrictive because a pose could be made up of several poses (e.g. one for
> the body, one for the right hand and one for the left hand), an outfit could
> be made up of an indeterminate number of items of clothing etc. I therefore
> started working on an alternative syntax that enables chains of properties
> files to be specified. For example, in this later version I can specify a
> walking pose followed by a pose that just adjusts the right arm to hold a
> cup.

Are we talking about different KeyFrames here?  He is walking by holding a cup?
He is walking and grabbing a cup and holding it?   Yes, I can see the need for
reusability in various poses applied to various body parts, and how wonderful
it will be if users can combine them.

The challenge here is, IMHO, to think of users' skill level, power users vs new
comers to POV_RAY and Animation.  Layering, for various skill levels of users
might be a good idea?


> > From my OOP days, I hope you will forgive me if I attempt to partition
> > your
> > design entities along MVC paradidgm lines:
>
> MVC is really an architectural pattern for server design (common in OO
> solutions). It's not particularly easy to map to it in this context but I'll
> try :-).

In my working days, it was used for client-server application development, that
were applications, that had heavy GUI components (=Viever), that did all the
heavy duty computations in the back (=Model) on a powerful server, and that
provided end-users with means to control what got calculated and displayed
(=controller), the client-server communications middleware protocols, etc.

See, I am day-dreaming of a GUI application where end user specifies which body
part go where, that is, records in some simplified textual interface
how to move.  Or better yet, some point and click interface, picks the segments
s/he wants to move, rotation slider to help her move that segment picked.  As
soon as data is collected, the humanoid demonstrates how that move would looks
like.  See, it was always been hard for me to remember the moves as I learned
my katas as I studied martial arts.  I had sketched, and developed some short
hand to help me remember.  Now, with my incrased memory problems visual memory
retention got even harder.  I am sure I am not the only one with Visual memory
problems, and some way to easily record, and be reminded of exercises would be
very welcomed.

Well, I am dreaming again.

>
> > Model is (a) the human. Hopefeully as a tree.  Any skeletal being could be
> > modeled using this joint-segment approach.  Humanoid is just one instance.
>
> Although conceptually it can usually be visualised as representing a
> tree-like structure, it's actually stored as a set of arrays accessed
> through macros. The main macro is 'ppAddJoint' which is used to 'describe'
> how the different body parts fit together and what constraints are
> applicable to each joint.

Yes, I have learned that that was your implementation. while I stop myself for
the language constructs that POV-RAY does not support, I see how single minded
I have gotten.

>
> Yes, this system can be used to describe any anatomy (even one with closed
> loops that would depart from a tree-like structure). It can even support
> multiple humanoid definitions. For example, I've been looking at the
> MakeHuman anatomy recently. It uses a more sophisticated shoulder
> construction which could potentially be reproduced in POV-Person by creating
> pphuman002.inc.

Oh my.  Yet another mind that never rests.

> >
> > View: (b) all visual attributes of our model some male some female
> > dependent?
> > Then at the model we could have divided it in male and female?,
>
> It would certainly be possible to define separate models for male and
> female. Indeed, Alf and Bob both use the ppm1 definition. Ann uses 'ppf1'
> and Babs uses 'ppf2'. At the moment a lot of the body parts referenced by
> these different figures use the same body part definitions just scaled up or
> down depending upon the gender settings (and other settings). For example,
> one finger nail definition serves for all fingers and toes for both male and
> female figures. Likewise the eyes, teeth, forearm etc. are reused for all
> models.
>
> The 'Style' settings (b) control attributes like hair and makeup, most of
> which are not defined to be gender specific. Although clearly certain
> hairstyles and patterns of makeup are more frequently associated with a
> particular gender, I've intentionally avoided imposing any such constriants
> in the code. The main exception I can think of is with the beard growth
> macro which, by default takes account of gender when deciding whether or not
> to add facial hair.
>
> >
> > Controller: (c) + (d) assuming they both give users means of making the
> > being
> > laugh, walk, talk, etc. etc.  As I read about character animation, I learn
> > that
> > facial expression and body expression are very closely related.  Like you
> > are
> > sad, your face registers it as your shoulders sags, your walk changes,
> > etc.
> >
>
> There is indeed a lot of commonality between the expression (c) and the pose
> (d) and the reorganisation of code following on from the release of V2A1
> blurs that distinction completely. These later modifications enable multiple
> pose and multiple expression settings to be layered on top of one another in
> any required sequence. This makes it theoretically possible to create a
> 'sad' file that reads the current joint settings and adds a little bit more
> slump to the shoulders and that also controls the definition of body parts
> to add a little bit of downturn to the mouth.
>
> > I would not even thought of including (e) as part of Humanoid object, it
> > is an
> > external entity.  Yes, there should be an easy way to apply that external
> > entity on the Humanoid.
>
> The intention of incorporating an outfit (e) into the definition was to
> enable the shape and form of the outfit to be determined by the anatomy and
> pose. So the size of the hat can be determined by the size of the head and
> the seam of the trousers can follow the line of the leg as it moves.

Makes sense.
>
> >>
> >> P.S. I wonder if I could use a freebee high poly count character I found
> >> on
> >> the internet and converted to .pov, as a skin, to your more robotic
> >> person, to
> >> inherit its movements?  Well, never mind that poly character did not have
> >> a
> >> head, only an anatomically acurate body, but then I discovered a paper
> >> that
> >> talked about how to create a head only using CSG.  Still too much to do.
> >>
>
> If you can convert body parts to objects that POV-Ray understands, such as
> mesh objects (PoseRay is usually good for doing such conversions) then the
> existing body parts can quite easily be selectively replaced. You could
> therefore potentially use the existing heads with the headless body you
> found.

PoseRay? ah one more thing I donot know about.  I discovered 3dWin5 V5.6 that
could convert a lot of other 3D formats to .pov scenes and back via my Google
searches.  It has done great job converting.  Also searching the web for
freeware 3d poly models, i had lots of good hits.  Some hits from 3Dmax and
Maya generated characters.  I downloaded them, converted them, they were
patiently waiting my sphere+cone Humanoid to finish learning how to move. Well,
s/he failed them.  without doing Inverse Kinematics, and without keeping track
of joint locations, I won't be able to teach him to walk right.  Not to forget
spline interpolations.
>
> If I'd have been able to find an open source figure around when I was
> writing POV-Person I'd have definitely been happier using that.

Well blobman figure is pretty good.  This other figure I had found, seemed just
a bit more like an anatomical book insert.  I  hope I can figure out how to
place my energy meridian interpolations.

Regards,
meltem
>
> Regards,
> Chris B.

Post a reply to this message